Universal Plug and Play (UPnP) is an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and personal computers (PCs) of all form factors. (See, e.g., “Universal Plug and Play Device Architecture, Version 1.0,” Microsoft Corporation (June 2000), and other documents available from the Universal Plug and Play Forum, such as at www.upnp.org on the Internet.) UPnP is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP is a distributed, open networking architecture that leverages TCP/IP and various other Internet/Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and public spaces.
UPnP technology is broad in scope in that it targets home networks, proximity networks, and networks in small businesses and commercial buildings. It enables data communication among devices under the command of any device on the network. UPnP technology is independent of any particular operating system, programming language, or physical medium.
The UPnP architecture supports zero-configuration networking and automatic discovery whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices and services. DHCP and DNS servers are optional and are only used if they are available on the network. A device can leave a network smoothly and automatically without leaving any unwanted state information behind.
UPnP uses multicast to send device and service announcements onto the network. In UPnP, a device is conceptually a container of services, and multicasts announcements of each of the services it contains. Accordingly, for expository convenience, the term “device” in this document refers to both devices and services. As a new UPnP-enabled device becomes available on a network, the device sends an announcement that includes an address of the device on the network along with the device's identity. On networks using Internet Protocol, version 4 (IPv4), an address is associated with an interface of a network node (e.g., a computer or other networked computing device). One or more UPnP-enabled devices may be hosted on a network node (such as a PC). A UPnP-enabled device also may exist as a network node independent of any host PC. A Universal Serial Number (USN) uniquely identifies each UPnP-enabled device, whether an independent device or residing on the host. When the address changes, the UPnP device sends another announcement with the same USN but with the new IPv4 address.
In the UPnP device architecture, a Control Point (CP) caches the network address of announced devices. Upon receiving a first multicast announcement with a device's USN, the Control Point stores the network address specified for the device USN in the announcement in a cache entry. As soon as the Control Point (CP) sees a new announcement coming from the same device (same USN) (e.g., after an address change), the Control Point deletes a previous cached entry and stores an entry with the latest network address for the device USN.
In some scenarios, such as where the UPnP device resides on a dual stack and/or multi-homed network node, there may be multiple network addresses associated with the UPnP-enable device. In which case, the UPnP-enabled device may multi-cast announcements with the different network addresses, although its location on the network has not changed. Recent developments in networking and computer usage create an increasing trend towards multi-stack, multi-homed network environments.
For example, many computing devices are now being designed and deployed with support for both Internet Protocol version 6 (IPv6), as well as IPv4. IPv6 is a “next generation” protocol designed by the Internet Engineering Task Force (IETF) to replace the current IPv4 protocol. IPv6 fixes a number of problems in IPv4, such as the limited number of available IPv4 addresses. It also adds many improvements to IPv4 in areas such as routing and network auto-configuration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a number of years during a transition period. During this transition, many network nodes may provide both IPv4 and IPv6 protocol stacks, so that the node can communicate with both IPv4 and IPv6 nodes on its network. Such nodes that provide more than one protocol stack are herein referred to as having “dual stacks.” UPnP devices hosted on such nodes generally will send announcements of both its IPv4 address and IPv6 address(es) (so as to announce itself to both IPv4- and IPv6-equipped Control Points).
As another example, some nodes provide multiple interfaces to attach to separate networks or network segments (e.g., an Ethernet adapter for connecting to a local area network (LAN), an IEEE 802.11b (Wi-Fi) card, an adapter for power-line or phone-line home networking, a Bluetooth interface, an IEEE 1394 (Firewire) interface, and etc.). This allows the node to operate simultaneously on multiple network segments, such as a Bluetooth-based “personal area network,” a wired LAN or home network, and a commercial wireless network. Such nodes with interfaces to multiple networks or network segments are herein referred to as “multi-homed.” In IPv6, as in IPv4, addresses are associated with an interface and not a node itself. In addition in IPv6, there can be numerous addresses associated with an interface, and there could be numerous interfaces associated with a node. Numerous interfaces associated with a node also can be true for multi-homed IPv4 nodes, which will generally have a separate IPv4 address for each interface. UPnP devices hosted on multi-homed nodes generally also will send announcements of the addresses associated with each of its node's interfaces, so as to announce itself to Control Points on each of the networks.
A problem arises with UPnP devices hosted on such multi-homed and/or dual stack nodes, in that UPnP Control Points that also are multi-homed and/or dual stack may receive the announcements of multiple addresses valid across multiple scopes for the UPnP device. The Control Point then is unable to differentiate an announcement sent over a separate network segment or protocol stack versus an announcement sent when the IP address of the UPnP device has changed. In accordance with conventional Control Point behavior, every new announcement therefore is interpreted as representing a device address change, which then causes the Control Point to replace its cached entry for the UPnP device. In a best case scenario, the same UPnP device's announcements sent across different network segments causes annoying flicker at the Control Point, as the Control Point repeatedly replaces its valid cached entries for the UPnP device. (An application user interface (UI) on the Control Point displaying UPnP devices present on the network typically updates with each cache entry added or removed). In some worse case scenarios, the network traffic unnecessarily increases, such as if the Control Point receives an announcement while already in the process of downloading the description document specified by the previous equally valid announcement. This situation can also expose some timing issues and race conditions. The bottom line is that network resources are used unnecessarily, and the user experience suffers.
This problem is not limited to the UPnP device architecture, but also can be encountered in other networking technologies that use multicast for device announcements and/or discovery.